2. Common Porting Issues



This chapter covers general problems and differences among other software development tools and CodeWarrior. The topics in this chapter describe the CodeWarrior features that have subtle and obvious differences from most other development environments.

This chapter has these sections:


C and C++ Issues

This section covers topics on differences between the CodeWarrior C and C++ compilers and other compilers:


About Metrowerks Standard Libraries

The Metrowerks Standard Libraries (MSL) for C and C++ comply with the libraries described by the ANSI/ISO C and C++ Standards.

MSL C and MSL C++ also have functions that are commonly available but are not part of their respective standards. For example, MSL C has functions that are commonly available in UNIX.


ARM and Other C++ Implementations

CodeWarrior C++ conforms to the ANSI/ISO C++ standard, although it has options to compile source code that conforms to the C++ specification in the Annotated C++ Reference Manual (ARM).

For information on compiling non-ANSI C++ source code, refer to the C, C++, And Assembly Language Reference.


CFront and Metrowerks C++

MSL C++ conforms to the ANSI/ISO C++ Standard for the C++ streams libraries. There are a few variations from the standard as accepted and published in such books as Stroustrup's The C++ Programming Language, 2nd edition (Addison-Wesly, 1991) and Stanley B. Lippman's C++ Primer, 2nd edition (Addison-Wesley, 1991) commonly referred to as the C++ Programming Language or CFront C++.

For information on compiling non-ANSI C++ source code, refer to the C Compilers Reference.


#include header naming conventions

ANSI C++ no longer require a file name extension for the include files. However, the file extension naming conventions are provided for by ANSI C++, and included in Metrowerks.

CFront C++


  #include <iostream.h>

ANSI C++


  #include <iostream>

File open modes

Listing 2.1 shows the valid combinations of ios::openmode for opening a file as defined in the ANSI C++ library-these are defined in terms of the equivalent modestr used in fopen(s, modestr) (see para 7.9.5.3 of ANSI Standard for C).


Listing 2.1 File open modes


ios::in   	modestr = "r"
ios::out | ios::trunc  	modestr = "w"
ios::out | ios::app  	modestr = "a"
ios::in  | ios::bin  	modestr = "rb"
ios::out | ios::trunc | ios::bin 	modestr = "wb"
ios::out | ios::app   | ios::bin 	modestr = "ab"
ios::in  | ios::out     	modestr = "r+"
ios::in  | ios::out   | ios::trunc 	modestr = "w+"
ios::in  | ios::out   | ios::app 	modestr = "a+"
ios::in  | ios::out   | ios::bin 	modestr = "r+b"
ios::in  | ios::out   | ios::trunc | ios::bin 	modestr = "w+b"
ios::in  | ios::out   | ios::app   | ios::bin 	modestr = "a+b"

All other combinations are invalid and no file is opened and no error message is produced.


File open and close testing

Use the is_open() function to test for an open file.

In CFront C++:


  ofstream to("testFile");    if (!to ) /* ... */

In ANSI C++:

  ofstream to("testFile");
   if (to.is_open() == 0) /* ... */

iostream fail() vs. eof()

Historically (before the advent of the ANSI/ISO C++ specification) the eofbit was set haphazardly. ANSI C++ libraries do not set the eofbit, therefore the previous practice of using the function eof(), which gave a non-zero result when the end of file was reached, is no longer useful. Instead you should test the value of the fail() function, which will pick up both eof and other kinds of failure, as shown in Listing 2.2.


Listing 2.2 fail() vs. eof()


#include <iostream>
#include <fstream>

void main() 
{    
  // fill file with 10 x's
         ofstream out("testfile");
         for(int i = 0; i < 10; i++ ) out.put( 'X');
         out.close();
 
        char c = 0;
        ifstream input("testfile");
 
    //  while ( !input.fail() )   this leaves EOF character
    //  while( input.peek() != EOF )this works but less safe
 	while ( !input.fail() && input.peek() != EOF )
        {
           c = input.get() ;
           cout << "char: " << c << endl;
       }
     input.close();
}


UNIX and POSIX Libraries

There are header files that provide some of the functions in the POSIX standard and many functions found in UNIX libraries that are not specified in the ANSI C or ANSI C++ standards.

Refer to fnctl.h, stat.h, unistd.h, unix.h, utime.h, and utsname.h in the C Library Reference for more information.


The sizeof() operator and int

When programming in C, do not assume that the value of a sizeof() operator is assignment compatible with the int or long data types.

According to the ANSI C standard sizeof() returns a value of type size_t, defined in stddef.h.

The size_t and int data types are often the same, but might differ depending on the platform or processor. Refer to Listing 2.3 for an example of how a program executes incorrectly when it assumes that size_t and int are the same size.


Listing 2.3 Making assumptions about sizeof() and int


#include <stdio.h>
#include <stddef.h>

typedef struct {
	char	bigArray[100000];
} MyStruct;

void main(void)
{
	int j;
	size_t t;
	

	j = sizeof(MyStruct); /* This doesn't work */
	t = sizeof(MyStruct); /* This works */

	printf("bad size of MyStruct = %ld\n", j);
	printf("good size of  MyStruct = %ld\n", t);
}

/* Output, running on Mac OS for 68K:

bad size of MyStruct = -2036334591
good size of  MyStruct = 100000

*/

There are a few variations from the MSL implementation of C++ and previous versions of ANSI/ISO C++. MSL C++ conforms as closely as possible to the ANSI/ISO C++ standard.


Mac OS Issues

The topics in this section deal with common problems you might have when porting your programming project to Apple's Mac OS. Of course, this section cannot cover every aspect of porting a project to a new operating system. Instead, it gives you tips and references to other documentation to help you.

The topics in this section are:


Where to Find More Information About Mac OS

You'll find comprehensive documentation, sample source code, and other resources for Mac OS development at Apple's web site for software developers, http://www.apple.com/developer/.

To learn how to use CodeWarrior to develop software for Mac OS, see Targeting Mac OS.


Console I/O for Mac OS

For programs that use simple text input/output without calling on any Mac OS-specific features, CodeWarrior provides SIOUX. SIOUX is a Mac OS software package that automatically opens a text window, accepts characters from the keyboard, and handles menus. SIOUX does all this transparently; you, the programmer, do not have to explicitly invoke SIOUX.

Simply by calling a standard C or C++ function that reads from or writes to the standard input, output, or error files will invoke SIOUX automatically.

Refer to the MSL C Reference for information on customizing SIOUX.


Command-Line Arguments for Mac OS

The C/C++ ccommand() function provides a dialog box that allows the user to enter text as if it were at the command line. Refer to ccommand() in the MSL C Reference for more information.


File Redirection for Mac OS

For UNIX-style file redirection, use the C/C++ ccommand() function. Refer to ccommand in the MSL C Reference for more information.


Including Files In C/C++ on Mac OS

When using CodeWarrior on Mac OS, CodeWarrior C/C++ handles subdirectory names in #include directives differently than UNIX compilers. In particular, Mac OS uses the colon, ":", as a directory separator character, not the slash, "/".

For example, when using CodeWarrior on a Mac OS computer, issuing this directive

  #include "special/datatypes.h"

will actually include a file named "special/datatypes.h," not the file "datatypes.h" in the "special" directory.


Specify Subdirectories for #include Directives

The recommended way to specify a directory for an #include directive is to add the directory to the list of access paths in the project's Access Paths project settings panel and remove references to subdirectories in all #include directives. Refer to the CodeWarrior IDE Guide for more information on access path preferences.

Another way to specify a subdirectory for an #include directive is to convert the pathname to a Mac OS pathname. For example

  #include "special/datatypes.h"

becomes

  #include ":special:datatypes.h"




Visit the Metrowerks website at: http://www.metrowerks.com
For assistance contact Metrowerks Technical Support at: support@metrowerks.com
Copyright © 1999, Metrowerks Corp. All rights reserved.

Last updated: March 01, 1999 * Chris Magnuson * John Roseborough